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Grasp — A  Graph  Specification  Language 


Todd  A  Gross 

Dept,  of  Computer  Science  and  Electrical  Engineering 
University  of  Nevada,  Las  Vegas 

October  13,  1988 


1  Introduction 

This  paper  is  an  introduction  to  Grasp,  a  language  for  defining  and  prototyping 
graph  theoretic  constructs  and  properties  associated  with  them.  The  language 
is  a  specification  language,  which  means  that  one  gives  only  the  necessary  inputs 
and  desired  outputs,  and  the  translator  generates  the  necessary  algorithm. 

Section  2  explains  why  Grasp  was  devised.  Section  3  gives  the  syntax  of 
the  language.  Section  4  gives  some  examples  of  Grasp  specifications.  Finally, 
section  5  discusses  the  relative  strengths  and  weaknesses  of  the  language. 

We  are  currently  developing  a  translator  from  Grasp  specifications  into  C 
functions. 


2  Purpose  of  Grasp 

Originally,  Grasp  was  intended  to  bring  together  two  until  now  distinct  fields  of 
computer  science:  program  synthesis  and  parallel  computation.  Due  mainly  to 
time  constraints,  we  have  pared  the  Grasp  project  to  development  of  a  translator 
from  Grasp  specifications  to  C  functions.  It  is  felt  that  later  work  could  add 
parallel  code  generation  and  optimisation  via  program  synthesis  theory  with 
only  a  minimum  of  rewriting  of  the  present  code. 

The  domain  chosen  for  this  research  (and  consequently  for  Grasp)  is  graph 
theory.  There  were  several  reasons  for  choosing  this  domain: 

•  It  is  an  abstract  domain,  meaning  there  are  relatively  few  details  to  keep 
track  of.  This  facilitates  synthesis. 

•  It  is  highly  amenable  to  parallelization,  as  graphs  are  just,  sets  of  ver¬ 
tices  and  edges.  Further,  as  graph  theory  asserts  properties  of  graphs, 
rather  than  forces  specific  calculation1,  we  can  assume  independence  of 

’Actually,  in  nonprocedural  languages  (like  Grasp  and  PROLOG),  calculation  of  results 
and  assertion  of  properties  are  interchangeable  paradigms.  Thus  a  clause  in  PROLOG  can  be 


calculation  over  the  set  of  graph  components.  This  greatly  simplifies  par¬ 
allelisation,  as  we  can  forego  dependency  analysis  [W0I88]. 

•  It  is  a  rich  domain,  including  several  problems  that  are  simple  to  con¬ 
ceptualise  but  hard  to  calculate.  One  of  these,  the  Travelling  Salesman 
Problem,  has  already  been  used  to  test  the  power  of  specific  parallel  pro¬ 
cessing  environments  iKTSfi). 

e  It  is  a  practical  domain,  as  many  real  problems  are  at  base  graph  theo¬ 
retic.  For  instance,  the  topologies  of  multiprocessor  networks  are  easily 
represented  as  graphs  ({Hil85],  Ch  3). 

The  present  system,  regardless  of  parallelism,  is  designed  to  allow  one  to 
define  a  nontrivial  set  of  graph  theoretic  properties.  It  uses  a  small  but  powerful 
set  of  operators,  as  this  is  easier  both  to  define  and  to  use.  Further,  Grasp 
specifications  are  nondettrminiMtie,  which  means  they  define  a  property  but 
not  how  to  compute  it.  This  greatly  facilitates  parallel  computation,  because 
we  are  free  to  take  advantage  of  all  parallelisation  inherent  in  the  problem. 
Nevertheless,  this  must  be  left  to  later  work. 


3  Syntax 

This  section  defines  the  set  of  legal  specifications  in  Grasp,  and  illustrates  the 
definitions  with  simple  examples. 


3.1  Identifiers 


Identifiers  are  names  that  are  bound  to  specific  Grasp  objects.  Most  objects 
in  Grasp  (or  any  other  language,  for  that  matter)  have  predefined  names.  For 
instance,  3  is  a  predefined  name  for  the  integer  value  3.  Only  two  types  of 
objects  in  Grasp  can  (and  must)  be  given  names  by  the  user:  variables  ($3.4) 
and  definitions  ($3-5). 

Identifiers  in  Grasp  must  begin  with  a  letter,  and  can  otherwise  consist  of 
letters,  digits,  and  underscores  (.).  They  can  be  arbitrarily  long,  but  if  it's  more 
than  32  characters  long,  any  extra  characters  are  right  truncated.  They  also 
cannot  be  any  of  the  25  reserved  words  in  Grasp.  The  language  is  case  sensitive, 
and  all  reserved  words  are  lower  case.  The  following  are  legal  Grasp  identifiers: 

i  iO  i  1  inTEGER  integers 
The  following  are  not  legal: 


Oi  i  integer 


seen  as  calculating  a  set  of  valid  answers  or  asserting  which  values  would  be  logically  consistent 
with  the  given  axiom*. 
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CD 


3.2  Types 

There  are  9  types  in  Grasp,  of  which  7  are  graph-oriented  (the  other  two  being 
the  standard  types  integer  and  boolean).  In  Section  1  we  define  the  9  types, 
including  the  syntax  for  literals  in  each  type,  and  in  section  2  we  define  classes 
of  types  that  are  used  in  defining  operator  syntax  (§3.3),  and  give  a  hierarchy 
of  the  type  classes. 

3.2.1  Type  Definitions 

Standard  Types  There  are  two  standard  types  in  Grasp:  boolean  and 
integer. 

The  boolean  type  is  exactly  as  in  Pascal:  there  are  two  possible  values, 
represented  by  the  literals  true  and  false. 

Integer  values  are  limited  by  the  C  compiler  one  runs  the  synthesized  rou¬ 
tines  on,  in  our  case  -2*°-l  to  2*°.  Note  that  while  integers  can  take  negative 
values,  there  are  no  literals  to  represent  negative  integers.  This  is  because  neg¬ 
ative  integers  are  rarely  needed  in  graph  theoretic  problems.  Thus  -3  is  an 
illegal  construct,  unless  preceded  by  something  that  evaluates  to  an  integer.  In¬ 
teger  literals  are  base  10  numerals,  without  any  intervening  symbols  (including 
commas). 

Graph  Types  To  facilitate  explaining  the  7  graph  types,  we  will  use  Figure  1. 

Basic  Components  The  basic  components  of  graphs  are  vertices  and 
edges.  The  corresponding  Grasp  types  are  vertex  and  edge  respectively. 

A  vertex  literal  is  represented  by  a  period  immediately  followed  by  an  in¬ 
teger.  There  are  6  vertices  in  the  above  graph,  labelled  1  through  6.  In  Grasp 
these  would  be  written  as  .1,  .2,...,  .6.  Note  that  we  are  not  forced  to  label 
vertices  with  consecutive  integers,  any  6  distinct  nonnegative  integers  would  do. 
For  instance,  if  we  wanted  to  use  all  primes  we  might  label  them  .2,  .3,  .5,  .7, 
.11,  and  .  13. 
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Ail  adg«  literal  is  represented  by  (i't ,  r-j  >.  where  t<t  and  t>i  are  vertex  literals. 
For  instance,  the  long  vertical  edge  between  .  1  and  .4  would  be  represented  by 
( .  1 ,  .4).  Edges  in  Grasp  are  undirected  (notice  the  lack  of  arrows  in  Figure  1), 
so  (.4,.l)  will  also  work,  but  Grasp  converts  this  to  the  first  form  because  it 
stores  all  edges  in  nondecreasing  older. 

In  fact,  (ni,«s)  is  a  general  form  for  edges,  meaning  that  t»i  and  can  be 
any  expression  that  evaluates  to  a  vertex.  For  instance,  if  variable  v  is  of  type 
vertex,  then  (v,  .2)  is  a  valid  edge  form 

Sets  of  Components  Grasp  also  lets  one  define  sets  of  basic  components — 
that  is,  vertex  sets  and  edge  sets.  The  corresponding  Grasp  types  are  vset  and 
eeet  respectively. 

Set  literals  are  represented  by  {  list  }.  whete  list  is  a  nonempty  set  of  either 
vertex  or  edge  literals  separated  by  commas.  For  instance,  {.3.  .6,  .0}  is  a 
vast  literal  that  represents  a  subset  of  the  vertices  in  Figure  1.  Again,  the  Older 
is  not  important,  so  {. 6 ,  .0,  .3}  will  werk  just  as  well.  East  literals  work  like 
vset  literals,  except  with  edges  rather  than  vertices,  so  {( .3,  .6)  ,  (  .6,  .0)}  is 
a  literal  that  contains  all  edges  in  Figure  1  with  both  vertices  in  {  .3,  .6,  .8}. 

Due  to  the  impossibility  of  maintaining  uniqueness  of  set  elements  (that 
is,  preventing  any  elements  of  a  set  from  repeating)  at  translate  time,  Grasp 
allows  sets  to  contain  any  sequence  of  elements,  as  long  as  they  are  the  right 
type.  For  instance,  {.2,  .  1 ,  .2}  will  be  accepted  by  Grasp  as  a  legal  vset.  We 
are  planning  to  add  a  routine  that  will  make  sets  proper,  but  this  must  wait  for 
the  rest  of  the  translator  to  be  constructed. 

Note  also  that  (  list  }  is  a  general  form  for  sets,  so  that  {at ,  ( .  1 ,  vl )}  is 
a  valid  eset  form,  given  el  is  an  edge  variable  and  vl  is  a  vertex  variable. 

Sets  of  Sets  When  determining  properties  of  sets  of  elements,  it  is  often 
necessary  to  generate  sets  of  sets.  For  instance,  we  say  a  set  of  vertices  is 
independent  if  no  two  distinct  vertices  in  shat  set  have  an  edge  between  them. 
Thus,  to  determine  if  a  vsat  is  independent,  we  need  to  generate  the  set  of  all 
2-element  subsets  of  our  vset.  The  Grasp  types  for  these  are  vsatset  for  sets 
of  vsats,  and  asetsat  for  sets  of  asats. 

Syntax  of  sets  of  sets  is  the  same  as  for  any  other  set,  the  only  difference  is 
the  elements.  A  vsatset  literal  might  look  like  this: 

{  {.1}  ,  {.1,  .2)  .  {.1.  .2,  .3}  } 

There  are  3  elements,  each  of  which  is  a  vset  literal.  The  structure  is  analogous 
for  asetsat  literals. 

The  general  form  for  sets  also  works  f:r  sets  of  sets.  Thus  the  following  is  a 
valid  vsetset  form,  assuming  V  is  a  vset.  and  vl  and  v2  are  vertex  variables: 

{  V  ,  {vl,  .r.  ,  {v2}  } 

Note  that  there  is  no  type  vsetsetset  for  <»ts  of  vsetsets.  This  is  because  such 
forms  are  only  useful  if  one  is  interested  ir  properties  of  sets  of  sets.  The  author 
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is  not  mt(  of  any  theories  about  sets  of  sets  of  vertires  or  edges,  therefore 
there  is  no  vsetsetset  or  esetsetset  type.  There  is  also  not  a  general  set  extension 
because  of  difficulties  with  dynamic  typing. 

Graphs  The  final  type  in  Grasp  represents  graphs  themselves — which  are, 
naturally,  the  main  focus  of  graph  theory.  The  corresponding  Grasp  type  is 
graph. 

A  graph,  mathematically  speaking,  is  just  a  set  of  vertices  and  a  set  of  edges 
on  those  vertices.  In  other  words,  a  vsat  and  an  atat.  The  general  form  for  a 
graph  is  {  vtei  I  eset  }  ,  where  vtei  evaluates  to  a  vset,  and  eset  to  an  eset. 
The  graph  literal  to  represent  the  graph  in  Figure  1  is: 

{  {.1,  .2,  .3,  .4,  .6,  .8}  I  {( . 1 , .2)  ,  (.1,-4),  (.2, .6), 

(.3, .4),  (.3.-8),  (.6. .8)}  } 

Note  that,  unlike  with  edges  and  sets,  the  order  of  placement  in  graphs  it 
important.  The  vertexset  must  be  to  the  left  of  the  vertical  bar,  and  the  edgeset 
must  be  to  the  right. 

3.2.2  Type  Hierarchy 

The  9  Grasp  types  are  mutually  disjoint,  which  means  that  no  value  can  belong 
to  more  than  one  type.  The  form  {  }  would  appear  to  be  a  legal  literal 
for  any  of  the  4  set  types,  but  it  is  not  allowed  in  Grasp.  Not  only  are  the 
9  types  disjoint,  they  are  also  mutually  incompatible,  which  means  no  value 
can  be  coerced  from  one  type  to  another.  For  example,  there  is  no  automatic 
conversion  of  the  vertex  .  1  to  the  vset  { .  i}  . 

Nevertheless,  we  can  talk  about  a  hierarchy  of  types,  because  certain  oper¬ 
ators  will  take  values  of  more  than  one  type.  For  instance,  there  is  an  operator 
to  find  the  number  of  elements  in  a  set.  This  operator  will  work  on  values  of 
any  of  the  4  Grasp  set  types.  We  give  4  type  classes  that  are  used  by  Grasp 
operators,  then  draw  a  Hasse  diagram  of  the  type  hierarchy. 

The  4  type  classes  are: 

smallset  A  set  of  graph  components — a  vsat  or  an  sset 

setset  A  set  of  sets — a  vsetsat  or  an  asatsat 

set  Any  set,  thus  either  a  smallset  or  a  setset 

element  Any  type  that  can  be  an  dement  of  a  set,  thus  a 

vertex  or  an  edge,  or  a  vset  or  eset,  as  these  are 
elements  of  their  corresponding  setsets. 

We  will  use  these  names  when  we  talk  about  types  of  operators  and  operands 
(53.3).  We  draw  the  type  hierarchy  in  Figure  2,  where  i  —  y  means  “expressions 
of  type  (class)  r  can  evaluate  to  type  (class)  y. 


h 


Figure  2:  The  type  class  hierarchy 


You'll  note  there  are  two  extra  type  classes  in  Figure  2:  varform  and  all- 
typesform.  A  varform  is  any  legal  Grasp  expression,  regardless  of  which  type 
it  evaluates  to  An  alltypetform  is  an  expression  that  can  conceivably  evaluate 
to  any  single  Grasp  type.  In  Grasp  thete  are  two  such  expressions:  variables 
($3.4)  and  definition  use  ($3.3.7).  They  were  added  to  the  diagram  for  the  sake 
of  completeness,  it  is  assumed  that  the  reader  is  familiar  with  this,  at  least  on 
a  syntactic  level. 


3.3  Operators 

There  are  21  operations  one  can  perform  in  Grasp,  each  of  which  has  its  own 
operator(s).  For  each  operation,  we  first  give  the  syntax,  where  a  type  class 
name  in  italics  means  an  expression  that  evaluates  to  that  type  class.  The  type 
class  to  the  right  of  the  arrow  represents  the  return  type  class.  Any  expression 
may  be  enclosed  in  parentheses  ()  and  retain  its  type  class. 


3.3.1  Arithmetic 

integer  *  integer  — •  integer 

integer  -  integer  — •  integer 

The  only  two  arithmetic  operations  allowed  in  Grasp  are  addition  (*•)  and 
subtraction  (-).  Arithmetic  expressions  are  evaluated  left  to  right,  and  both 
operators  are  strictly  binary.  For  example,  5-3-1  evaluates  to  1,  and 
-  3  -  1  is  illegal.  Parentheses  can  be  used  to  override  left  to  right  evaluation, 
so  6  -  (3  -  1)  evaluates  to  3 


3.3.2  Relational 


( varform  -  rarform)  — »  boolean 

( varform  /=  rarform)  — •  boolean 

In  Grasp,  one  can  only  test  for  equality  or  inequality  of  two  expressions,  as 
“greater  than*  does  not  apply  well  to  vertices  or  edges.  While  one  can  have 
any  Grasp  expression  on  either  side  of  the  relational  operator,  the  expressions 
on  both  sides  of  the  operator  must  evaluate  to  the  same  type,  wet  «  eset  won't 
work,  even  though  both  are  elements  of  class  smallset,  and  may  even  have  the 
same  syntax. 

Notice  that  relational  expressions  are  enclosed  in  parentheses.  This  avoids 
the  problem  of  a  =  b  =  c,  where  a,  b,  and  c  are  all  boolean  variables.  One  can 
enclose  relational  expressions  in  as  many  pairs  of  parentheses  as  one  wishes,  as 
long  as  one  has  at  least  one  pair. 

3.3.3  Logical 

not  boolean  — •  boolean 

boolean  and  boolean  — >  boolean 

boolean  or  boolean  - -  boolean 

Logical  operators  in  Grasp  are  just  like  in  Pascal,  and  and  or  evaluate  left  to 
right,  with  no  guarantee  of  early  evaluation  (that  is,  falsa  and  x  and  y  may 
or  may  not  evaluate  i  and  y  though  the  expression  will  evaluate  to  falsa  in  any 
case),  and  and  has  higher  precedence  than  or. 


3.3.4 

Graphical 

first 

edge 

— •  vertex 

last 

edge 

— ♦  vertex 

vset 

graph 

— •  vtet 

eset 

graph 

— •  eset 

Curiously,  out  of  21  operations  available  in  Grasp,  only  4  specifically  operate 
on  graphs  or  graph  components — the  rest  operate  on  integers,  booleans,  sets, 
or  definitions.  And  there  is  no  operator  whose  sole  operands  are  vertices. 

first  and  last  take  an  edge  and  return  one  of  the  component  vertices  For 
instance,  first  (.1,  . 3)  returns  .  1,  and  last  (.1,  . 3)  returns  . 3.  Remem 
ber,  though,  that  edges  are  put  in  nondecreasing  order  by  the  Grasp  translator, 
so  that  first  (.3,  .  1)  will  also  return  .1. 

vset  and  eset  take  a  graph  and  return  the  component  vertex  set  and  edge 
set  respectively  Given  a  graph  G  =  {  (.1,  .2}  :  { ( .  1 ,  . 2 ) }  }.  vset  G  eval¬ 

uates  to  {  .  1  ,  .2}  and  eset  G  to  { ( .  1 ,  .  2)  }.  vset  and  eset  are  also  the  names 
Grasp  uses  for  the  corresponding  types,  but  the  translator  can  discern  which 
use  is  intended  Isee  ($3.2.1)). 


3.3.5  Set  Oriented 

*  tet 

— . 

rnfejer 

( element  in  set) 

_ . 

boolean 

■ax  refiet 

— . 

smallset 

■In  tetset 

— * 

smallset 

null  settype 

— 

set 

variable  of  set  st  boolean 

— 

set 

subsats.of  smallset 

_ , 

tetset 

in  the  above  description,  when  element  and  set  appear  in  the  same  statement, 
the  types  of  the  corresponding  values  must  correlate.  For  instance,  if  the  tel 
expression  evaluates  to  type  vsat,  the  element  expression  must  evaluate  to  type 
vertax.  The  same  rule  applies  between  smallsel  and  tetiei.  For  instance,  if  the 
tmalltei  expression  evaluates  to  type  asat,  the  tetset  expression  must  evaluate 
to  type  asataat. 

Sise  operator  The  first  operator,  #,  is  the  size  operator.  That  is,  it  tells  you 
how  many  elements  are  in  a  set.  For  instance, 

f  {( . 1 , .4)  .  (.2, .3)} 

evaluates  to  2.  as  there  are  2  edges  in  the  eset,  but 

*  {  {(•*.. 4).  (.2, .3)}  } 

evaluates  to  l,  as  there  is  1  eset  in  the  esetset. 

Element  operators  The  next  three  operators  are  element  operators,  which 
means  they  operate  on  individual  elements  of  the  set.  The  first  of  these  is  the 
in  operator,  which  discerns  whether  a  given  element  is  in  a  given  set1.  Notice 
that  the  expression  is  in  parentheses,  it  was  necessary  to  enclose  in  expressions 
in  parentheses  to  keep  our  grammar  LALR(l)3.  For  instance.  ((.2,-1)  in 
{(.1,.2),  (.  2  ,.  3) })  evaluates  to  true.  But  note  that  in  only  evaluates  1 
level,  so  that  (. 2  in  {  {.1}  ,  {.2,  .3}  J)  (rerter  in  wetsei)  will  not  work. 

The  other  2  operators,  nax  and  nin.  take  a  set  of  sets,  count  the  number  of 
elements  in  each  individual  set.  and  return  the  set  with  the  greatest  and  fewest 
number  of  elements  respectively.  If  there  is  more  than  one  largest  (or  smallest) 
set,  it  returns  the  first  one  it  finds,  which  is  not  guaranteed  to  be  the  first  one 
in  the  set.  For  example,  if  S  ={{•  1 }  ,  {.1,  .2}  ,  {.t,  .2,  .3}  }.  then 
max  S  evaluates  to  {.  1 ,  .2,  . 3}  and  min  S  evaluates  to  {.  1 }. 

^Analogous  the  Pascal  in  operator. 

*  Later  versions  of  Grasp  should  fie  this  kludge. 
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Null  »et  operator  The  next  operator,  null,  defines  a  null  set  of  type  settype, 
which  can  be  any  of  the  4  Grasp  set  types.  Thus,  for  example,  null  v«et  defines 
an  empty  vertex  set. 

Subset  operator  The  next  operator,  the  of . .  .at  operator,  is  a  subset  oper¬ 
ator,  which  means  it  generates  a  subset  of  the  set  given  to  it  (as  the  set  operand 
just  after  the  word  of).  It  generates  a  subset  by  selecting  those  elements  that 
satisfy  a  boolean  expression  (given  after  the  word  st)V  Let  me  give  an  example: 

V  of  {  {.1}  .  { . 1 , . 2)  }  st  #  V  =  1 

Assume  V  is  a  variable  of  type  vset.  The  set  we’re  taking  a  subset  of  is  a 
vsetset  with  2  elements.  Each  element  is  bound  to  ¥,  then  tested  to  see  if  its 
site  equals  1  (#  V  =  1).  In  this  case,  the  test  holds  on  the  first  element,  but  not 
on  the  second,  so  the  expression  evaluates  to  a  set  containing  the  first  element, 
or  {{.!}}. 

Notice  that  the  first  operand  is  a  variable  of  the  proper  element  type.  It 
exists  only  to  bind  individual  elements  of  the  set  to  be  evaluated  by  the  boolean 
function.  Everywhere  the  operand  appears  in  the  boolean  expression,  it  is  re¬ 
placed  by  an  element  of  the  set  operand.  But  there  is  nothing  that  requires  one 
to  use  this  operand.  In  particular: 

variable  of  set  st  true 


evaluates  to  set,  and 


variable  of  set  st  false 

evaluates  to  the  empty  set  of  that  specific  type.  This,  by  the  way,  is  a  way 
of  generating  an  empty  set,  although  the  null  operator  is  the  more  preferable 
means  of  generating  a  null  set.  Mostly,  this  form  is  used  in  quantificational 
expressions  ($3.3.8),  but  it  can  be  used  anywhere  one  wants  to  generate  a 
subset. 

Power  set  operator  The  last  operator,  the  subsats.of  operator,  generates 
all  subsets  of  a  set — or  if  you  prefer,  the  power  set  of  a  set.  Clearly,  the  base 
set  must  be  a  smallset,  as  we  will  generate  a  set  of  sets. 

Earlier,  we  gave  a  definition  of  an  independent  set  of  vertices;  and  said  that 
we  would  have  to  generate  all  2-element  subsets  of  the  vset  to  determine  if  it’s 
independent.  Letting  V  be  our  vset,  and  ¥2  be  a  vast  variable,  we  can  generate 
the  2-element  subsets  with  this  Grasp  expression: 

¥2  of  subsets-of  ¥  st  #  ¥2  =  2 

This  expression  is  the  same  as  the  one  above,  only  we’ve  replaced  a  vsetset 
literal  with  a  power  set  expression  and  changed  the  sire  of  the  desired  vsets 
from  1  to  2. 


4st  stands  for  such  that 


3.3.6  Quantificational 


(for all  tabtetexp)  t  boolean  ]  — •  boolean 
(axlst e  lubsetezp}  [  boolean  ]  — >  boolean 

Quantificational  expressions  are  the  most  complicated  ones  in  Grasp,  but 
they  are  also  the  most  useful:  they  allow  the  user  to  determine  complex  proper¬ 
ties  of  graphs  using  tools  they  are  likely  to  be  already  familiar  with.  The  word 
su  btetexp  in  the  above  syntax  definitions  refers  to  expressions  using  the  of. . .  st 
operator. 

The  expression  takes  the  variable  the  of. .  .st  expression  used  to  bind  ele¬ 
ments  of  the  set  operand  and  binds  elements  of  the  subset  to  it.  This  is  then 
substituted  into  the  boolean  expression  enclosed  in  brackets,  one  at  a  time. 
What  the  entire  expression  evaluates  to  depends,  naturally,  on  whether  the  key 
word  is  forall  or  exists. 

If  the  key  word  is  forall,  then  the  expression  evaluates  to  trua  iff  the 
boolean  expression  evaluates  to  true  for  each  element  of  the  subset,  otherwise 
it  evaluates  to  false.  If  the  keyword  is  exists,  then  the  expression  evaluates 
to  false  iff  the  boolean  expression  evaluates  to  false  for  each  element  of  the 
subset,  otherwise  it  evaluates  to  true. 

An  example  will  help: 

(forall  v  of  {.1,  .2,  .3}  st  true) [v  =  .1] 

First,  look  at  the  juiietetp.  We  want  to  generate  the  set  of  all  elements  in 
{■1,  .2,  .3}  such  that  trua  is  true.  As  you'll  recall  from  ({3. 3. 5. Subset), 
this  gives  us  back  our  original  set.  So  our  tubtetexp  is  {  .  1 ,  .2,  .3}.  Now  we 
take  each  element  of  this  set,  bind  it  to  v  (assuming  v  is  a  vsrtsx  variable),  and 
evaluate  the  boolean  expression  v  =  .1.  For  the  first  element,  this  evaluates  to 
trua,  but  for  the  other  two  it  evaluates  to  false.  Since  it  doesn't  evaluate  to 
true  for  every  element  in  the  subset,  the  entire  expression  evaluates  to  false. 

But  notice  what  happens  when  we  teplace  forall  with  exists: 

(exists  v  of  {.I,  .2,  .3}  st  true)[v  =  .1) 

Again,  for  the  first  vertex,  the  boolean  expression  evaluate  to  true,  and  for  the 
second  and  third  it  evaluates  to  false.  Since  they  didn't  all  evaluate  to  false, 
the  entire  expression  evaluates  to  true. 

Now  for  a  more  complicated  example.  Remember  that  we  defined  a  vertex 
set  to  be  independent  iff  for  every  pair  of  distinct  vertices  in  the  vertex  set  there 
are  no  edges  between  them.  This  is  the  Grasp  equivalent  of  our  definition: 

(forall  vl  of  V  st  true)  [ 

(forall  v2  of  V  st  vl  /=  v2)  ( 
not  ((vl,v2)  in  eset  G) 


We  will  study  this  example  mote  closely  in  Section  4,  but  for  now  notice  that  we 
have  a  netted  quantificational  expression.  The  syntax  is  important,  the  entire 
quantiflcational  expression  must  go  inside  the  brackets. 

To  evaluate  this,  first  we  generate  the  outer  subset,  in  this  case  our  input 
vset  V  and  bind  a  specific  element  of  it  to  vl.  Using  this  binding,  we  evaluate 
the  inner  expression.  We  generate  the  inner  subset,  in  this  case  T  minus  vettex 
vl,  and  bind  an  element  of  that  set  to  v2.  Then  we  evaluate  the  expression  in 
the  innermost  brackets,  with  both  bindings  in  effect.  In  effect,  we  will  generate 
all  pairs  of  vertices  (»j,  vj)  such  that  t>t  and  are  in  V  and  distinct  from  each 
other.  Thus,  using  nesting,  we  can  have  as  many  bound  variables  as  we  like. 

3.3.7  Definition  Use 

defnxd  (  argliit  )  — •  deftype 

Definitions  are  the  basic  components  of  Cl  rasp  specifications,  just  as  func¬ 
tions  are  the  basic  components  of  C  programs.  And  as  one  call*  a  function 
in  C,  one  uses  a  definition  in  Grasp.  We  will  give  the  syntax  of  definitions  in 
(§3.5).  For  now  we  stick  to  using  a  definition:  defnid  is  an  identifier  bound  to 
a  definition,  arghst  is  a  nonempty  list  of  arguments  to  the  definition  separated 
by  commas,  and  deftype  is  the  type  of  the  value  the  definition  generates. 

For  instance,  let’s  assume  we’ve  created  a  Grasp  definition  of  an  independent 
set.  Our  definition  requires  two  pieces  of  information:  the  vaat  we’re  testing 
for  independence,  and  the  aaat  where  any  edges  between  our  vertices  may  lie. 
Let’s  assume  this  information  is  stored  in  varibles  7  and  E  respectively,  let's  also 
assume  the  definition  is  named  lndapandant.  Then  we  can  use  our  definition 
on  V  and  E  by  writing 

independent ( V , E ) 

3.4  Variables 

Variables  in  Grasp  are  identifiers  that  are  bound  at  any  one  time  to  an  arbitrary 
value  of  a  predefined  type.  In  Grasp,  three  operations  can  be  performed  on  a 
variable:  declaration,  binding,  and  use. 

Declaration  binds  an  identifier  to  a  storage  location  and  a  concomitant  type. 
A  variable  must  be  declared  before  it  can  be  bound  or  used,  and  it  cannot  be 
rededated  in  the  same  definition  (§3.5).  Thus  the  scope  of  a  variable  is  from 
the  point  of  declaration  to  the  end  of  a  definition.  The  syntax  for  declaration  is 

"typenamf  identifier" 

where  typename  is  one  of  the  9  Grasp  type  names  given  in  (§3.2).  For  instance, 
"vertex  v"  declares  a  vertex  variable  and  associates  the  identifier  v  with  it. 
Variables  can  be  declared  anvwhere  in  a  definition,  as  long  as  its  name  has  not 
previously  occurred  in  the  definition.  But  there  is  no  declaration  statement,  it 
is  done  at  the  first  occurrence  of  the  identifier  in  the  definition. 
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Binding  assigns  a  value  to  a  variable.  In  fact,  only  subset  and  quantifica- 
tionai  expressions  bind  variables — where  elements  of  sets  are  bound  to  a  variable 
for  application  to  a  boolean  expression.  In  particular,  it  should  be  noted  that 
there  is  no  assignment  operator  or  statement  in  Grasp.  In  this  way,  Grasp  vari¬ 
ables  are  not  like  variables  in  procedural  languages  like  C  or  Pascal.  Typically, 
Grasp  variables  are  declared  and  bound  at  the  same  point  in  the  specification. 

Use  binds  the  value  associated  with  a  variable  to  an  expression.  For  example, 
suppose  that  the  value  associated  with  variable  x  is  .3.  Then,  in  the  boolean 
expression  x  in  { .  1 ,  .2},  we  use  x  to  get  the  expression  .3  in  {.1,  .2}, 
which  can  be  evaluated.  Until  now,  every  occurrence  of  a  variable  in  a  sample 
expression  has  been  a  use  or  binding.  In  the  next  section,  we  will  start  giving 
the  proper  declarations  before  using  or  binding  a  variable. 

3.5  Definitions 

Definitions  are  the  basic  components  in  Grasp.  lust  as  a  C  program  consists 
solely  of  a  set  of  functions  (plus  global  definitions),  a  Grasp  specification  consists 
solely  of  a  set  of  definitions.  Like  functions,  definitions  have  a  set  of  input 
parameters  and  return  a  value.  Like  functions,  definitions  can  be  invoked  by 
giving  their  name  followed  by  a  parenthetically  enclosed  set  of  arguments. 

But  unlike  functions,  definitions  do  not  do  anything.  They  only  specify  the 
desired  output  for  a  set  of  inputs,  it  is  up  to  the  Grasp  translator  to  generate 
functions  that  can  generate  the  desired  outputs. 

The  syntax  of  a  definition  is 

id  (  aryltst  — >  type  )  :  property 

where  id  is  the  identifier  bound  to  a  definition,  arglut  is  the  set  of  input  pa¬ 
rameters,  type  is  the  type  of  the  value  the  definition  evaluates  to  (like  a  return 
value,  except  we're  not  “return”ing),  and  property  is  an  expression  evaluated 
using  the  variables  in  argtist. 

Let’s  start  with  a  simple  example: 

vcount ( "graph  G"  -->  intagar)  :  »(vaat  G) 

This  is  a  definition  of  the  number  of  vertices  in  a  graph  G.  The  name  of  the 
definition  is  vcount,  thete  is  one  input  to  the  definition  G — which  is  the  graph 
we're  counting  the  number  of  vertices  of.  We  say  that  vcount  is  a  defintion  over 
Q  Notice  that,  since  this  is  the  first  appearance  of  G  in  the  definition,  we  have 
to  declare  it.  In  fact,  this  will  be  true  of  everv  input  to  a  definition. 

Definitions,  like  functions  in  procedural  languages,  generate  one  output. 
Since  the  number  of  vertices  in  a  graph  is  an  integer,  the  output  to  vcount 
is  of  type  integer.  We  say  vcount  evaluates  to  an  integer,  the  tvpe  our  defini¬ 
tion  evaluates  goes  after  the  — >  token  and  before  the  right  parenthesis. 

Then,  after  the  colon,  we  have  the  actual  definition:  a  Grasp  expression 
that  evaluates  to  the  proper  type  (presumable,  though  not  necessarily,  using 
the  inputs  to  the  definition).  To  distinguish  fh'  expression  that  embodies  the 
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definition  from  the  entire  definition,  including  the  input  and  output,  we  some¬ 
times  call  it  a  property  of  its  inputs.  Thus,  in  the  case  of  vcount,  *( vset  6)  is 
a  property  of  G.  The  property  can  use  any  of  the  21  Grasp  operations,  in  any 
combination  where  operator/operand  types  match,  but  it  must  include  at  least 
one.  Thus  the  following  silly  definition  would  be  illegal: 

[*  three  Illegally  defines  3  to  be  a  property  of  graph  G  •] 
three ("graph  G"  — >  integer):  3 

But  the  following  equally  silly  definition  is  legal: 

[• 

new  three  legally  defines  3  to  be  a  property  of  graph  G 

*] 

neo. three ( "graph  G"  — >  integer):  2+1  C*  Uses  the  +  operator  *) 

Notice  that  the  preceding  definitions  had  comment ».  Comments  in  Grasp 
are  like  comments  in  C,  except  that  the  delimiters  are  [*  and  *]  instead  of  /* 
and  */. 

4  Examples 

We  now  give  some  examples  of  Grasp  specifications,  which  show  the  full  range  of 
expression  in  the  language,  and  also  its  application  to  well-known  and  important 
graph-theoretic  problems. 

4.1  Independent  Set 

Our  first  example  is  a  correct  Grasp  definition  of  an  independent  set: 

[* 

independent!)  defines  the  concept  of  a  set  of  vert¬ 
ices  V  being  independent  with  respect  to  a  graph  G 

*] 

independent ("vset  V",  "graph  G"  — >  boolean)  : 

(forall  "vertex  vl"  of  V  st  true)  [ 

(forall  "vertex  v2"  of  ?  st  vl  /=  v2)  [ 
not  ((vl,v2)  in  eset  G) 

] 

] 

This  is  the  definition  we  gave  in  (53.3.8),  with  the  proper  declarations  and 
definition  header.  We  used  the  same  name  as  in  (53.3.7),  but  you'll  notice  that 
instead  of  an  eset  input  we  have  a  graph  input.  The  reason  is  twofold:  an 
eset  need  not  be  associated  with  a  graph,  but  we  want  to  know  if  a  vset  in  a 


particular  graph  is  independent — that  is,  if  any  edges  tn  the  graph  we  took  the 
verticet  from  straddle  any  two  of  our  vertices. 

Let's  look  at  the  definition  line  by  line.  Lines  1-4  are  a  comment  document¬ 
ing  the  definition.  Line  6  is  the  definition  header,  and  gives  the  information  any 
other  definition  will  need  to  know  to  use  it.  It  gives  the  definition  name,  the 
two  input  paramaters,  and  the  result  type.  Notice  we  have  more  than  one  input 
parameter.  As  in  most  programming  languages,  when  we  use  this  definition  we 
must  give  the  arguments  in  the  same  order  as  the  parameters. 

Lines  5-9  constitute  the  body  of  the  definition.  The  body  (or  if  you  prefer, 
property)  is  a  nested  quantiAcational  expression.  Lines  5  and  6  bind  variables 
vl  and  v2  to  different  elements  of  V:  line  5  binds  vl  to  an  arbitrary  element 
of  V  and  line  6  binds  v2  to  any  element  that  isn't  the  same  as  vl.  Since  each 
variable  is  eventually  bound  to  every  member  of  its  corresponding  subset,  these 
2  lines  generate  the  set  of  all  nonequal  pairs  of  vertices.  Line  7  takes  each  pair 
of  vertices  after  binding  and  tests  whether  the  corresponding  edge  exists  in  G. 
This  definition  will  evaluate  to  true  only  when  no  such  edge  exists  in  G  for  any 
pair  of  distinct  vertices  in  V.  Which  correlates  to  our  English  definition  of  an 
independent  set  of  vertices:  that  thete  be  no  edges  between  any  two  of  them. 

4.2  Vertex  Degree 

According  to  (BM76),  the  degree  of  a  vertex  v  is  “the  number  of  edges  of  G 
incident  with  v,  each  loop  counting  as  two  edges."  Then  in  the  Figure  3,  .  1  has 
a  degree  of  3,  and  .2  has  a  degree  of  1. 
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Figure  3:  Graph  G 

A  Grasp  definition  of  vertex  degree  looks  like  this: 

[* 

The  degree  of  a  vertex  v  with  respect  to  a  graph  G 
is  defined  as  the  number  of  edges  in  G  incident  to 
v,  counting  loops  tvice. 

*] 

degreeC'vertex  v",  "graph  G"  — >  integer)  : 

#(”edge  el”  of  eset  G  st  (v  =  first  el))  + 

tf'edge  e2"  of  eset  G  st  (v  =  last  e2)) 

First  of  all,  notice  that  this  definition  generates  an  integer.  Although  most 
definitions  will  generate  boolean  values  (as  we  are  usually  interested  in  whether 
a  property  holds  for  a  given  graph  (component)),  many  generate  other  values. 
It  is  even  possible  to  genetate  graphs,  although  the  svntax  is  quite  clumsy. 


Lines  8  and  9  constitute  the  body  of  the  definition.  Notice  that  they  ate  very 
similar  to  each  other,  the  only  differences  are  the  names  for  the  edge  variables 
and  the  operations  performed  on  them.  We  could  have  used  the  same  variable 
on  both  lines,  but  we  wanted  to  show  that  each  line  generates  a  distinct  subset, 
even  though  both  use  aaet  G  as  their  base.  Line  8  generates  the  set  of  all 
edges  that  have  v  as  its  first  component,  then  counts  how  many  there  are. 
Line  9  counts  how  many  edges  have  v  as  their  fast  component.  These  counts  are 
then  added  together  to  get  the  incidence  count,  i.e.  the  degree.  Although  the 
following  definition  looks  like  it  would  work  (and  is  perfectly  legal),  it  doesn't 
count  loops  twice: 

degree("vertex  v",  "graph  G"  — >  integer)  : 

#("edge  eM  of  eset  G  st  ((v  =  first  •)  or  (v  =  last  e))) 

4.3  Path  Between  Vertices 

An  important  concept  in  graph  theory  is  the  notion  of  a  path ,  a  set  of  edges 
such  that  given  a  specific  list  of  vertices,  there  is  an  edge  containing  the  nth  and 
n  +  1th  vertices  in  the  list,  so  long  as  n  is  a  positive  integer  less  than  the  number 
of  vertices  in  the  list.  For  instance,  given  the  eset  {( .  1 ,  .3) ,  ( .2,  .3)},  we  can 
create  the  vertex  list  .1  .3  .2.  There  is  an  edge  between  .1  and  .3  (.1,.3), 
and  an  edge  between  .3  and  .2  ( .2,  .3).  Figure  4  is  a  picture  of  the  path. 


Figure  4:  The  path  {(.1,.3),  (.2, .3)} 

And  this  is  a  Grasp  definition  of  a  path  between  two  vertices: 

[* 

A  path  to  vertex  v2  from  vertex  vl  exists  in  graph  G  iff  one 
can  create  a  list  of  vertices  in  G  such  that  vl  is  the  first 
vertex,  v2  is  the  last  vertex,  and  any  tuo  consecutive  vertices 
comprise  an  edge  in  G. 


path-to("v#rtax  vl" ,  "vertex  v2",  "graph  G“  -->  boolaan)  : 

(  (vl,v2)  in  aaet  G  }  or 

(axlata  "vertex  v"  of  veat  G  it  (  (vl,v)  in  aiat  G)  ))  [ 
path.to(v,  v2,  { 

"vertex  a"  of  vaat  G  at 

(s  /=  vl) 

I 

"edge  f"  of  aaat  G  at 

not((vl  =  first  f)  or  (vl  =  last  f)) 

} 

) 

] 

Notice  that  the  definition  is  recursive,  which  is  to  say  it  uses  itself.  Notice 
though,  that  each  time  we  use  the  definition,  the  graph  gets  smaller:  we  remove 
a  vertex  from  its  vset,  and  all  edges  containing  that  vertex  bom  its  eaet.  Even¬ 
tually  we  will  either  have  (vl,v2)  as  a  legal  edge  in  G  or  we  will  run  out  of 
edges  that  are  connected  to  vl. 

The  basic  structure  of  this  definition  is:  there  is  a  path  from  vl  to  v2  if 
either  (a)  (vl,v2)  is  an  edge  in  the  graph  or  (b)  there  i*  another  vertex  v 
in  the  graph  such  that  (vl,v)  is  in  the  graph  and  there  is  a  path  from  v  to 
v2.  The  problem  with  the  definition  in  this  form  is  that  it  doesn't  force  us  to 
make  progress.  If  (vl  ,v3)  were  an  edge  in  G,  then  path-to(vl  ,v2,G)  could  use 
path  to(v3,v2,G)  (substituting  v3  for  v)  which  could  then  use  path  to(vl  ,v2,G) 
(substituting  vl  for  v),  which  takes  us  back  where  we  started.  This  is  why  we 
reduce  the  graph  with  each  use.  Lines  II-I7  generate  the  reduced  graph  by 
using  the  general  form  for  graphs*. 

Earlier  we  mentioned  that  edges  in  Grasp  are  automatically  canonized.  The 
main  reason  this  is  done  is  to  make  writing  specifications  easier.  Note,  for 
instance,  that  we  wrote  (vl,v2)  in  eset  G  but  not  (v2,vl)  In  asat  G  in 
the  definition  of  path  to.  We  didn't  have  to,  even  though  we  don’t  know  (and 
can’t  know  in  general)  whether  vl  or  v2  will  appear  first  in  the  edge.  This  is 
the  advantage  of  canonizing  edges:  we  never  have  to  write  a  separate  expression 
for  each  possible  edge  form. 

4.4  Connected  Graphs 

We  say  that  a  graph  is  connected  if  there  is  a  path  from  every  vertex  in  the 
graph  to  every  other  vertex  in  the  graph.  Or  wore  simply,  if  there  is  only  one 
“piece’’  in  the  graph.  All  3  graphs  we’ve  drawn  so  far  have  been  connected 
graphs,  figure  6  shows  a  graph  that  isn’t  connected,  as  there’s  no  path  from  .  1 
to  any  other  vertex. 

Now  we  give  the  Grasp  definition: 

’This,  by  the  way,  is  the  clumsy  syntax  l  alluded  to  earlier. 


Figure  5:  A  nonconnected  graph 


C* 

k  graph  la  defined  to  ba  connected  if  there  la  a  path  from 
every  vertex  to  every  other  vertex  in  the  graph. 

•] 


connected( "graph  G"  — >  boolean)  : 

(forall  “vertex  vl“  of  vaet  G  at  true)  [ 

(forall  “vertex  v2“  of  vaet  G  at  (v2  /=  vl))  t 
path.to(vl  ,v2,G) 

] 


] 

Notice  the  similarity  between  this  definition  and  our  definition  of  Independent. 
Both  operate  over  pairs  of  vertices,  but  connected  tests  for  paths  between  ver¬ 
tices,  and  Independent  tests  for  a  lack  of  edges  between  vertices  (which,  by  the 
way,  doesn’t  mean  that  there  can’t  be  paths  between  the  vertices).  Notice  also 
that  we  used  the  definition  of  path  to  in  this  definition— we  used  it  to  define  a 
path  between  two  vertices. 

By  now,  one  should  be  familiar  enough  with  Grasp  syntax  to  be  able  to  read 
relatively  simple  definitions  (like  connected  above)  and  be  able  to  ascertain 
their  meaning. 


5  Conclusions 

We  have  not  yet  produced  a  Grasp  translator,  so  the  conclusions  we  reach  are 
based  on  the  inheres;  capabilities  (or  the  lack  thereof)  of  the  language.  In  trying 
to  define  properties  -f  graphs  using  Grasp,  we  have  found  it  to  be  a  surprisingly 
powerful  language.  If  one  can  come  up  with  a  systematic  way  of  defining  a 
property,  it  appear'  one  can  use  Grasp  to  define  it.  This  is  not  to  sav  that 
it  is  always  rosy  to  define  such  a  property,  we  have  found  that  concepts  that 
naturally  belong  lo»-thrr  sometimes  need  to  be  separated  in  the  definition  For 


instance,  if  we  want  to  say  that  an  edge  contains  a  vertex,  we  have  to  say  it’s 
either  the  first  component  or  the  last  one 

There  are  two  main  problems  with  Grasp  as  a  language.  The  first  is  a  lack 
of  special-purpose  operators.  For  example,  when  defining  path.to,  it  would 
have  been  easier  if  we  had  an  operator  that  subtracted  a  vertex  from  a  graph 
as  defined  in  ([BM76j  (§1.4)).  But  as  long  as  the  language  has  a  good  general 
set  of  operators,  it  was  felt  that  these  operators  could  be  added  later. 

The  second  problem  is  mote  serious.  The  calculation  involved  in  generating 
a  graph  property  appears  to  be  enormous,  because  we  tend  to  have  to  generate 
and  test  all  possible  operands.  For  instance,  in  path.to,  given  a  graph  G.  we  will 
generate  G  -  v  for  all  vertices  v  in  G  And  for  each  of  these  graphs  we  generate 
G  -  v  -  v'  for  all  vertices  »'  in  G  -  r  and  so  on.  That’s  0(n!)  graphs  we  have 
to  generate!  It  would  be  much  cheaper  to  use  transitive  closure  to  determine 
which  vertices  are  connected,  but  Grasp  doesn't  have  matrix  operations.  For 
now,  we  are  content  to  have  a  general-purpose  experimental  language. 

But  even  with  its  apparent  faults  the  language  holds  great  promise.  In 
[Bal87],  Douglas  Baldwin  discusses  th»  failure  of  current  programming  lan¬ 
guages  to  effectively  handle  parallelirable  problems.  He  cites  four  problems 
in  particular,  each  of  which  would  be  handled  by  the  complete  Grasp  system: 

1.  Data  Dependencies  Because  the  user  cannot  assign  values  to  variables 
or  determine  order  of  execution,  he  or  she  cannot  create  data  dependencies. 
Thus  we  are  free  to  find  and  utilize  all  available  parallelisation. 

2.  Data  Parallelism  As  we’ve  said  before,  graphs  are  merely  sets  of  vertices 
and  edges,  all  of  which  are  very  similar  to  each  other.  Therefore,  a  high 
degree  of  data  parallelism  will  be  inherent  in  a  typical  Grasp  specification. 

3.  Granularity  Because  there  are  many  parallel  operations  over  sets  of 
highly  similar  data  in  the  typical  Grasp  specification,  and  one  has  complete 
data  independence,  one  is  free  to  divide  the  problem  into  components  of 
very  specific  number  and  site.  Granularity  can  closely  match  the  specific 
hardware  and/or  software  one  is  operating  under. 

4.  Generality  Grasp  is  not  a  general  purpose  language.  But  it  generates  C 
functions,  thus  it  is  possible  to  use  the  general  purpose  capabilities  of  O. 
In  particular,  it  is  possible  to  cal!  external  C  functions  using  definition  use 
syntax*. 

It  is  hoped  that  further  work  will  extend  the  present  system  to  include 
parallelism  as  originally  intended. 

*Gr«sp  defintions  will  In*  translated  direr:!  ('  functions,  and  definition  uses  to  <’  func¬ 
tion  calls.  So  as  far  a*  the  C  compiler  is  cor.c*rned.  they  are  completely  interchangeable. 
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